test(tokens): add UnspentTokensIteratorBy prepared-statement comparison benchmark#1855
Open
sid200727 wants to merge 1 commit into
Open
test(tokens): add UnspentTokensIteratorBy prepared-statement comparison benchmark#1855sid200727 wants to merge 1 commit into
sid200727 wants to merge 1 commit into
Conversation
Contributor
|
Hello @sid200727 , See my comment in #1183 (comment) If the query is dynamic, then I am wondering how do we determine which parameter combinations are actually common enough to justify pre-prepared statements? Wouldn’t identifying these combinations require runtime tracking/analysis, and could that add additional overhead or complexity? Regards, |
…on benchmark Extracts the query-building logic from UnspentTokensIteratorBy into a standalone buildUnspentTokensIteratorByQuery function (pure refactor, no behavior change), and adds a new benchmark comparing: - UnspentTokensIteratorBy_Dynamic: the current production path, which builds and executes the query fresh on every call. - UnspentTokensIteratorBy_Prepared: the same query, prepared once via readDB.PrepareContext and reused across calls via stmt.QueryContext. Same seed and worker config as the existing baseline (1000 tokens, wallet0/GOLD, 4 workers, 5s window) so results are directly comparable. Median of 3 runs against Postgres: - Throughput: 3,334 -> 3,879 ops/s (+11%, range +6.5% to +17%) - P99 latency: ~8.3ms -> ~2.1ms (-73%, consistent across all runs) - Allocs/op: 131-132 -> 27 (-80%, deterministic across all runs) See discussion on LFDT-Panurus#1183. Signed-off-by: Siddhi Khandelwal <siddhi.200727@gmail.com>
sid200727
force-pushed
the
test/prepared-statements-benchmark
branch
from
a96dd50 to
3c9d830
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a benchmark comparing
UnspentTokensIteratorByexecuted via the current dynamic query-building path against the same query executed via a statement prepared once and reused, to get concrete numbers for the discussion in #1183.Changes
-> Extracted the query-building logic from
UnspentTokensIteratorByinto a standalonebuildUnspentTokensIteratorByQueryfunction (pure refactor, no behavior change — verified via existingTestTokenssuite, all 28 subtests pass includingListUnspentTokensByWallets)-> Added
RunUnspentTokensIteratorByPreparedComparisonbenchmark comparing:UnspentTokensIteratorBy_Dynamic: current production path (query built + executed fresh each call)UnspentTokensIteratorBy_Prepared: same query, prepared once viareadDB.PrepareContext, reused viastmt.QueryContext-> Wired into the existing Postgres benchmark suite as
BenchmarkTokenStorePreparedComparisonResults (median of 3 runs, same seed as existing baseline: 1000 tokens, wallet0/GOLD, 4 workers, 5s window)
Testing
Verified with
-count=3, all runs consistent. ExistingTestTokenssuite passes unchanged, confirming the query-building extraction preserves behavior.Notes for the Reviewer
Related to #1183. This PR is the measurement step only, no production behavior changes. Happy to proceed with the actual prepared-statement implementation (pre-prepare fixed variants + fallback to dynamic building, per the design discussed on the issue) if these numbers make the case.